II. Remarks 

Reconsideration and allowance of the subject 
application are respectfully requested. 

Claims 33-42 and 50-52 are pending in the application. 
Claim 33 is independent. 

Applicants have added new dependent Claims 51-52 to 
afford themselves a scope of protection commensurate with the 
disclosure. The new claims are fully supported in the 
specification and Drawings, and are believed to be allowable for 
the reasons to be developed below. 

Claims 33-42 and 50 were rejected as being 
unpatentable over Schneier and Pease , for the reasons discussed 
on pages 2-5 of the Office Action. Applicants respectfully 
traverse all art rejections. 

Independent Claim 33 recites a novel combination of 

steps for a business process for creating a secure game contract 

over a network. A game contract agreement is generated by 

determining a game contract rule set, determining a set of game 

expectations for one or more game contracting parties, and 

determining potential game contract outcomes. Initial game 

conditions are received for game contract generation from the 

one or more game contracting parties. The game contract 

activity is carried out according to the game contract rule set 
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such that the one or more game contracting parties act in a 
synchronized manner according to the game contract rule set and 
the set of game expectations. A non-refutable game contract log 
is generated detailing all contract transactions. A theoretical 
game contract log is generated detailing expected game contract 
transactions based on the game contract rule set, the set of 
game expectations, and the game initial conditions. The game 
contract transactions recorded in the game contract log are 
verified by comparing the game contract transactions in the game 
contract log to the expected game contract transactions in the 
theoretical game contract log. 

In contrast, none of the cited art (including Schneier 
and Pease ) discloses or suggests such a combination of game 
contracting steps . 

Schneier relates to computer device and method for 

encoding a message corresponding to an outcome of a computer 

game. In the Office Action, the Examiner alleges that Col. 40, 

line 59 through Col. 41, line 67 of Schneier discloses: 

generating a non-refutable game 
contract log detailing expected game 
contract transactions based on the game 
contract rule set, the set of game 
expectations, and the game initial 
conditions (see Page 3, fourth full 
paragraph of the Office Action) . 
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However , there is no claim element as recited above. 
Apparently, the Examiner has combined two claim elements 
together: 

generating a non-refutable game 
contract log detailing all contract 
transactions ; 

generating a theoretical game 
contract log detailing expected game 
contract transactions based on the game 
contract rule set, the set of game 
expectations, and the game initial 
conditions; and 



Neither Schneier nor Pease discloses or suggests the 
two claimed features disclosed above. The referenced Col. 40, 
line 59 through Col. 41, line 67 of Schneier discloses: 



An entire tournament for a group of players 
may be held on a single game computer 14. In 
this connection, the game software 15- may 
have the capability to set up a tournament 
schedule for multiple head-to-head matches. 
Players purchase machine readable codes or 
messages that, when entered into the game 
computer 14, are employed by the game 
software 15 to direct the game computer 14 
to set up the tournament. The tournament 
format may be "round robin, " where each 
player plays everyone else in the group, a 
"Swiss system, " where a limited number of 
rounds are established with the players 
having the best scores being matched against 
each other (i.e., an elimination protocol), 
or some other format well known in the art. 
All players competing in the tournament 
enter their name and player ID into the game 
computer 14. The game software 15 generates 
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the tournament schedule, and after each 
head-to-head match, records the outcome. At 
the conclusion of the tournament, a winner 
is declared and the tournament standings are 
printed on the computer display. The final 
outcome of the tournament may be certified 
by the central computer 12 utilizing any of 
the above-described protocols. 
Alternatively, each head-to-head game 
outcome may be certified by the central 
computer 12 in the same fashion. 

Computation of player ratings is implemented 
by the rating/ranking module 55 in the 
central computer 12 using known principles. 
Alternatively, ratings may be calculated on 
the player's game computer 14. These ratings 
are dependent upon past player and opponent 
performance and skill. For example, player 
"A" may have achieved 5 wins and 5 losses 
against relatively weak competitors, while 
player B has 3 wins and 20 losses against 
world-class competitors. This makes 
comparison between players difficult. The 
player's respective ratings take the 
relative skill of the competitors into 
account. Chess ratings are a good example. 
In accordance with well-known rating 
protocols, such as those developed by the 
statistician Dr. Arpad Elo, chess ratings 
range from 0 to 3000 with a mean of 1500. 
Every 200 points represent one standard 
deviation from the mean. Thus, a rating of 
2100 represents ( three standard deviations 
above the mean. The larger the rating 
differential between the stronger player and 
the weaker player, the greater the 
probability of the stronger player winning 
the match. A player rated 200 points higher 
than another player, for example, may be 
expected to win 75 games out of 100, while a 
player rated 400 points higher than another 
may be expected to win 90 games out of 100. 
After each game, points are added to the 
winner's rating and subtracted from the 
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loser's rating. The number of points won or 
lost is dependent upon the rating 
differential. Therefore, defeating a 
"weaker" player in lieu of a "better" player 
causes relatively fewer points to be added 
to the winner's rating. The present 
invention provides for generating ratings 
for players of computer games. The player's 
new rating is calculated after the outcome 
of the head-to-head game is certified. An 
exemplary rating formula may be 
characterized as follows: Winner's new 
rating=old rating* (x*rating dif f erence) +y . 
If, for example, x=0.04 and y=16, and 
assuming a 2000 player beats a 1700 player, 
the 2000 player \s new rating is computed as 
2000+ (04* (-300) ) +16=2004 . The loser's rating 
becomes 1696. If a 1300 player beats a 1500 
player, the 1300 player's new rating becomes 
1300+(0.04*200)+16=1324. The loser's new 
rating becomes 1476. Thus, the greater the 
rating differential between players, the 
larger the rating changes after the games if 
the underdog wins. If the stronger player 
wins, his or her rating increases by a 
relatively smaller value. After new ratings 
are computed, the rating/ranking module 
directs the central computer 12 to update 
the player information database 48 and/or 
outcome database 50 to reflect the changes. 

In any head-to-head * embodiment , it is 
possible to equalize the playing conditions 
for players of differing ability by 
utilizing player handicaps to generate game 
initialization variables that provide the 
lesser rated player of the game with more 
lives, more ammunition and the like, or 
conversely, which reduce the number of 
lives, ammunition and the like for the 
higher rated player. 
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Nothing in this passage (or any other passage of 
Schneier ) discloses or suggests the two claimed generating steps 
noted above. Accordingly, the salient claimed features of the 



present invention are nowhere disclosed or suggested by 
Schneier . 

In the Office Action, the Examiner admits that 

Schneier fails to disclose the claimed step of: 

verifying the game contract 
transactions as recorded in the game 
contract log by comparing the game contract 
transactions in the game contract log to the 
expected game contract transactions in the 
theoretical game contract log. 

However, the Examiner alleges that this feature is 
disclosed at Fig. 4 and Col. 4, lines 34-64 of Pease: 



A further object of the present invention is 
to provide an integrated secure casino 
gaming system with a central game controller 
that controls operation of a game of chance 
and maintains player accounts, which 
associates with critical files control words 
depending on the data contents of the 
critical files, and which checks the 
critical files at intervals to ensure that 
the control words are appropriate given the 
contents of the files, thus preventing 
unauthorized tampering with the critical 
files . 

Another object of the present invention is 
to provide an integrated secure casino 
gaming system with a central game controller 
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that controls operation of a game of chance 
and maintains player accounts, wherein 
modified checksums are associated with 
critical files and the validity of the 
checksums for such files is checked at 
intervals during system operation. 

A further object of the present invention is 
to provide an integrated secure casino 
gaming system with a central game controller 
that controls operation of a game of chance 
and maintains player accounts using a double 
entry bookkeeping system. 

Yet another object of the present invention 
is to provide an integrated secure casino 
gaming system with a central game controller 
that controls operation of a game of chance 
and maintains player accounts, wherein a 
double entry bookkeeping system is used to 
maintain player accounts such that the total 
of a group of accounts in the system is 
maintained at a constant value, with the 
group of accounts being totaled at intervals 
during operation of the system to detect any 
tampering with account data. 

Respectfully, there is nothing in this passage (or 

any other passage) of Pease which discloses or suggests 

verifying the game contract transactions as recorded in the game 

contract log by comparing the game contract transactions In the 

game contract log to the expected game contract transactions in 

the theoretical game contract log. Pease 1 s discussion of 

verification is of the game software/code via checksum or hash 

word, not the game play. The double entry bookkeeping is there 

for monitoring player accounts, not ensuring fair/secure game 
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play. Reference is clearly made to critical files and checking 
that the game system software is valid. Accordingly, the 
salient claimed features of the present invention are nowhere 
disclosed or suggested by Pease. 

Lastly, Applicants respectfully traverse the 
combination of Schneier and Pease on the ground that no 
convincing motivation has been shown on the record for combining 
these disparate systems. 

In view of the above amendments and remarks, it is 
believed that this application is now in condition for 
allowance, and a Notice thereof is respectfully requested. 



15 

WAS01 j»1643590J_213446_00015 4/3/2006 3:08 PM 



Applicants' undersigned attorney may be reached in our 



Washington, D.C. office by telephone at (202) 625-3507. All 
correspondence should continue to be directed to our address 
given below. 



Patent Administrator 
KATTEN MUCHIN ROSENMAN LLP 
525 West Monroe Street 
Chicago, Illinois 60661-3693 
Facsimile: (312) 902-1061 
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Respectfully submitted, 




Attorney for Applicants 
Richard P. Bauer 
Registration No. 31,588 



